feat(libkernel): support microsecond timeout in size-0 _umtx_op - #5887

@CnRJay I disassembled PS5Util.prx.guest.prx (e.g. from PPSA18194) to inspect zlqfTyrQSPk (RVA 0x102a0):

140010340: mov %rdx, %r8          # arg 5: timeout pointer
140010343: mov %rsi, %rdx         # arg 3: val
140010346: mov $0x2, %esi         # arg 2: UMTX_OP_WAIT (2)
140010232: push $0xffffffffffffffff; pop %r9 # arg 6: -1
140010236: xor %ecx, %ecx         # arg 4: sizeArgument = 0
140010238: jmp *_umtx_op          # tail call directly into _umtx_op

zlqfTyrQSPk is a plain thunk that explicitly clears %ecx and jumps directly into _umtx_op without performing any conversion. Callers in Sony's libc.prx (e.g. call_once) also pass sizeArgument = 0 with 4-byte microsecond timeouts. This confirms that the console's _umtx_op itself treats sizeArgument == 0 as a 32-bit microsecond count.

I have updated the PR following the second approach:

• Dropped the validity heuristic: when sizeArgument == nullptr, _umtx_op reads a 32-bit microsecond count unconditionally.
• Added a test case in GuestUmtxOp.cpp where the 4-byte microsecond count is followed by zeroed padding on the stack/struct (zeroNeighbours), ensuring it expires in 20 ms without hanging.
• Updated the existing failsafe waiters in GuestUmtxOp.cpp to explicitly pass SizeOf(sizeof(failsafe)) when passing a KernelTimespec.
• Updated docs/dev/debt/libkernel.md accordingly.

AI Assisted: Yes

Thanks for the disassembly. It shows zlqfTyrQSPk passes the pointer through without converting it. Together with the MGS4 caller that stores param_2 * 1000 in a 4-byte local, that's good evidence the console's _umtx_op reads a 32-bit microsecond count for size 0. Dropping the heuristic is the right call.

One thing to check before this goes in. The entry on main (from #1482) says PPSA12544's PS5Util.prx passes a timespec. If that call also uses size 0, the unconditional rule now reads the low 32 bits of tv_sec as microseconds. A 1 s wait would silently become a 1 µs wait. Could you check how PPSA12544 calls it (the size argument and what it stores), or run it with this change and confirm its waits are unchanged? If it passes size 16, the entry can just say so. If it really passes a 16-byte timespec with size 0, the two callers contradict each other and one of the two claims needs another look.

Also, the test change removes the checks that a size-0 timeout with too many nanoseconds or negative seconds throws. That's expected now. If no other test covers the explicit-size path, the same two timespecs passed with SizeOf(sizeof(KernelTimespec)) would keep its EINVAL covered.

@CnRJay I inspected PPSA12544's binaries (PS5Util.prx, libc.prx, eboot.bin):

• PS5Util.prx in PPSA12544 does not actually import _umtx_op (04AjkP0jO9U). Its synchronization imports in the PLT/GOT are sceKernelSyncOnAddressWait (Hc4CaR6JBL0), sceKernelSyncOnAddressWake (q2y-wDIVWZA), and sceKernelSleep (-ZR+hG7aDHw).
• The only PS5Util.prx that imports and calls _umtx_op is the one in PPSA18194 (via zlqfTyrQSPk), which explicitly passes sizeArgument = 0 with a 4-byte microsecond count.
• Running PPSA12544 with this change progresses immediately into asset loading and launches all its worker threads (Job.Worker 0..15, Background Job.Worker 0..15, presenter, UnityGfxDeviceWorker) without any synchronization delays or hangs.
• There is no conflicting caller passing a 16-byte timespec with size 0.

Regarding the tests:

• Updated RejectsAnInvalidTimeout() in GuestUmtxOp.cpp so that both UMTX_OP_WAIT and UMTX_OP_WAIT_UINT are tested with SizeOf(sizeof(KernelTimespec)) for negative and tooManyNanos, keeping EINVAL fully covered on the explicit-size path.

Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.

Checked on Linux: Ubuntu 26.04 (WSL2), GCC 15.2.0, Release, this head (4b34a6d5a) merged onto main 489466d3f (clean merge).

• With the change: guest_umtx_op and guest_sync_on_address pass, 3 rounds; no compiler warnings.
• Without it (main's SyncOnAddress.cpp, the new test kept): guest_umtx_op does not finish in 3 of 3 runs; ctest kills it at its 20 s timeout. Here main reads the 4-byte count plus the bytes after it as a timespec, which on this run gives a deadline that does not expire, where MGS4 got the not-a-valid-timespec throw. So the result on main depends on the neighboring stack bytes, as CnRJay pointed out.
• check_conventions.py --base origin/main passes.

Not checked: Windows, macOS, the title.

AI-assisted: yes (Claude Code).

Thanks for checking PPSA12544. If its PS5Util.prx doesn't import _umtx_op at all, the old debt note was about another path, and the unconditional size-0 rule has no conflicting caller. @isnisk's run also confirms the failure mode on main: the new test hangs there, with a deadline that depends on stack contents. Both of my points are covered. Nothing more from me.

Checked the build and the libkernel test suite (175 tests green, guest_umtx_op passes), and that the new test fails when the SyncOnAddress.cpp change is reverted. The size-0 read as a 32-bit microsecond count matches the callers disassembled in the thread, and the debt entry is updated; merging.